APPENDIX 



Menu Commands 



Viva 1.0 



The Menu Commands of VIVA allow you to display, enter, edit, and save VIVA programs. 

File Menu Load and display VIVA projects 

Edit Menu Graphical editing, cutting and pasting 

View Menu View Options 

System Menu Target system selection and control 

Help Menu Assistance to tiie user. 
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File Menu 



Viva 1.0 




The file menu deals with loading, saving, and executing VIVA programs. Many of these commands are 
available as Function Keys, and from the ToolBar by clicking on the corresponding icon. 



New Project m 
Open Project I 
Save Project 1 

Save Project As ! 

New Sheet E 



Duplicate Sheet 

Open Sheet i 

Save Sheet As \ 

Convert Sheet to Object 1 

Delete Sheet 1 

Piay/Stop M 
Print 

Print Setup 



Clears all objects, pages, and Modules, 
Loads and displays a VIVA project. 
Saves the current project 

Saves the cua-ent project with the name you specify. 
Creates a new sheet or Behavior Page. 

Saves and renames the current project 
Loads a sheet from a file. 

Saves the current sheet with the name you specify. 

Captures sheet behavior as a VIVA Module, 

Erases and deletes the current Behavior Page. 

Executes the behavior on the displayed Behavior Page. 

Prints the current sheet. 

Sets up the printer options you specify. 
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Exit Quits VIVA. 
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New Project Command 



?T Viva 1.0 





Clears the current 
conditions- 



Project and Behavior Pages. This function is equivalent to a reset of VIVA to the initial 



WARNING 

Be sure to save your work to a file before selecting this function. The New Project function deletes all 
work. All work may be lost. 
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Save Project Command H 




has been saved, it can be retrieved using OeenProiect ! 
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This saves an entire project with the new name you provide. As with Save Project, this procedure saves 
all of the sheets (Behavior Pages), all of the data sets, the Ul Form, and everyth^ else associated with a 

project After a project has been saved, it can be retrieved using Open Project 
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Save Sheet As Command I 

This saves a Behavior Page to a file with the name you specify. Because there is no limit to the number 
of VIVA Modules you can place on a Behavior Page, this feature enables you to create Librariesof VI VA 
Modules. 



Viva 1.0 




Sctve Sheet A?;^ 
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Convert Sheet To Object Command 




Once you have defined a Behavior Page for a VIVA Module, you can then convert the Behavior Page into 
a VIVA Module, Inputs and outputs of the Module are the same order and type as defined for the 
Behavior Page, Before saving the Module, you are given a final chance to enter the information about 
the Module (things like giving the Module a name, naming the input and output nodes, and documenting 
the function of the Module and how it is intended to be used). This is done through the Convert Sheet 
Dialog Box. To maintain universality, this interface is essentially the same as ttie Edit Attnbutes Dialog 
Box. 




Notes: 

1 . This dialog is probably the best interface provided for naming Module nodes. We recommend you 
name Module nodes here. 

2. Documentation should be provided at this point, to define the function of the Module, its intended 
uses, and restricfions in its use. 

3. Overloading is a characteristic that allows you to write several versions of the same behavior to 
handle the various implementation requirements. As a result, you can have three or four different 
addition Modules. In many of these cases, you will use a prior implementation as a template for the n€ 
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behavior. In these instances, you have the option of either updating the existing Module or creating a 
new one. 

4. You also have the option of selecting for the Module the appropriate Tree Group in the Object Tree . 
Typical Tree Groups include Bit Operations, Arithmetic Operations. Test Modules, and so forth. 
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Delete Sheet Command 




Viva 1.0 




This command closes the currently displayed sheet Any Infer mation on the sheet is lost 
You wiH receive a warning screen to verify that you really do want to delete the sheet 
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Run Behavior Page 



When you click on the Play/Stop button, VIVA will execute the Program specified by the cuaent visible 
Behavior Page. 



Viva 1.0 
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Inputs and Ou^uts to the process will be the inputs and Outputs specified on the currently visible 
Behavior Page, 

RESTRICTIONS 



To execute a VIVA program, none of the Inputs on the currently visible Behavior Page can be of type 
Variant OthenA^ise, an error will occur. 
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Print Command 
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Print Setup Command 




This command allows you to specify the options that will be used by the Print command. 
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Exit 

This command doses down ViVA. Any information you have not saved will be lost 
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Edit Menu 




The Graphical User Interface of ViVA supports the Windows-standard editing Hot Keys for copy 
(controi-C), cut (control-X), paste (control-V). and delete. The same commands can also be activated 
through the Edit Menu. To copy an object or group of objects, the object(s) must first be selected. This 
can be done in a number of ways: 

1 . To select a single object, click on it with the mouse, 

2. To select a group of objects, draw a box around the group. Click on the comer of the box. Then, 
while holding the left mouse button down, drag the mouse position until the box contains \he desired 
objects. 

Groups of objects can be copied between different Behavior Pages. 

Note 

VIVA does not use the standard Windows citpboard. As a consequence, objects cannot be moved 
across fdes, and selected objects are no longer available after ViVA has been stopped. 
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View Menu 




The view menu allows you to control the displayed level of detail. Many of these commands are available 
as Hot Keys, and from the ToofSar by clicking on the corresponding icon. 

View Dotacis 



View Object Names 



\ Displays the object name above each object 



View Node Names 



i Displays each node name instead of each node's icon. 



View Nodes 



^Si Displays node colors on Transports . (Node colors correspond to 
data types). 



Sort by Tree Group/Name 



\ Sorts the Object Tree in alphabetical order. 



Descend into Sheet 



This displays the Behavior Page of the selected object {This 
feature is also available by double-clicking on the object) 
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View Object Names 

Allows you to view the names of the Objects or Modules on a Behavior Page . On a standard Behavior 
Page, the node names are suppressed. 

The following graphics display a Behavior Page with and without the object names displayed. 
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View Node Names 

Allows you to view the names of the Modules or Nodes on a Behavior Page . On a standard Behavior 
Page, the icons of the various Modules are displayed and the names are suppressed. When Node 
Names are displayed, the icons are suppressed. 

The following graphics display a Behavior Page with and without the Node Names displayed. 
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Sort by Tree Group/Name 

This sorts all composite objects in the Object Tree in alphabetical order. 




$-|| BitOpefations 
S- II Sj>stem Low Level 
Test Pages 
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Descend into Sheet 

The Behavior Page of a VIVA Module can usually be displayed by either double clicking on the object, or 
by clicking on the descend icon after the Module has been selected using a left mouse dick. 
The following is the Behavior Page for an Exclusive OR Module. 
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System Menu 




The System Menu enables you to select and control the Target System. 

Open System 1^8 Select the target system (X86 or Floating Point Gate An-ay). 

View Ut Form This feature allows you to review the cuaently selected User Interface Form. This form 
controls the display and entry of data that is passed between you and VIVA, 

New Ul Form New Ui FORM. This allows you to select a new User interface Form, items that appear on 
the form are controlled through the System Interface. In summary, any system hook or event can be 
placed on an interface form. 

The available selections for target systems and user interfaces are alt maintained in the directory 
C:\VIVA\VIVASYSTEM. 

Merge and Save Systems are advanced features reserved for developing new system interfaces. 
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Open System 




Selecting the target system. At the time of composition, the availabie target systems were the XILINX 
Floating Point Gate Array (BaseXPoint) interfaceand the X86 User Interface. To take advantage of the 
massively parallel capabilities of VIVA, the ultimate target would be an FPGA or other massively parallel 
system. The X86 system defines the interface with your computer, and allows you to develop VIVA 
software without requiring that an FPGA board be present. 



Note: Just because the BaseXPoint FPGA interface has been selected does not necessarily mean that 
all computing functions will be allocated in GateWare^. In the first place, the User Interface must exist 
on the User's computer. External devices are allocated elsewhere. Optimization of physical allocation of 
resources is done by the Search Engine, and is done at compile time. The Search Engine selects from 
the list of available system resources in order to achieve performance at the required Information Rate. 

Forcing GateWare To force any particular VIVA Module into GateWare, set the System Attribute String 
of the Module to contain tfie desired system. 
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VIEW Ul Form 

This allows you to view the current User Interface Form, such as the one below. 
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NEW Ul Form 



This allows you to select a new User Interface Form. Items that appear on the form are controlted 
through the System Interface, in summary, any system hook or event can be placed on an interface form. 




I- 

ru 
ru 

fU 
Q 
u 



114 



Help Menu 




The Help Menu provides access to the Help System. 

The About option tells the version of VIVA currently being used: 
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ToolBar Controls 

The Graphical User Interface of VIVA was designed to allow you to specify the desired behavior of the 
target computer environment. 

Fife Commands 



\ New Project 



1 Open Project 



Clears all objects, pages, and Modules. 
Load and display a VIVA project 



i Save Protect 



Saves the current project 



I Save Project As 



Saves and renames the current project projects. 



[ New Sheet 



Creates a new blank sheet. 



^ Duplicate Sheet 
i Open Sheet 
I Save Sheet As 
i Convert Sheet 



Duplicates the current sheet. 



Loads a sheet from a file. 



Saves current sheet as a file. 



Captures sheet behavior as a VtVA Module, 



I Delete Sheet 

B Run/Stop 
View Details 



Erases and deletes current Behavior Page. 



Executes the behavior on the displayed Behavior Page. 



i View Object Names 
I View Node Names 



The names of the objects are displayed above the objects. 

The names of the nodes of the objects are displayed instead of the 
object's icon. 



i View Nodes 



The node colors are displayed on Transports . (Node colors correspond 
to data types,) 



Pi 



I Sort by Tree Group/Name Sorts the Object Tree in alphabetical order. 



Descend into Sheet Display the Behavior Page of the selected object (Also available by 
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double-clicking on the object) 
i Open System Selects the target system. 

I View Ul Form Displays the User Interface Form. 

i New Ul Form Allows you to Select a new User Interface Form. 
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VIVA will then present the DataSet Editor (below). The window on the right contains the DataSet Tree, 
defining alt of the existing data sets. To review the contents of any of these DataSets, either activate it 
using the drop-down menu under the DataSet Name, or drag the desired DataSet to the DataSet Name 
in the left pane. 

To create a new data set, first enter the new DataSet Name. Next define the components of the Data 
Set, by dragging them from the menu of available DataSets, (VIVA will not let you type them in as they 
must be preexisting and dragging eliminates tfie possibility of a typing error.) 
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Note: Most of the existing software is geared toward processing DataSets with two components. 
Although the system allows for more, sometimes unusual results occur. Limiting the number of DataSet 
components to two is not really a restriction, because component parts can always be combined pair wise 
to make up any composite DataSet. 
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Edit Attributes Dialog 




The Edit Attributes Dialog Box enables you to enter the information about a Moduie. The information may 
include giving the Module a name, naming the input and output nodes, and documenting the function of 
the Module and how it is intended to be used. To show the Dialog Box, right click on the Module to be 
affected. To maintain universality, this interface is essentially the same as the Convert Sheet to Object 
Dialog Box . This Dialog Box is also used for defining the OataSets for Module inputs and Outputs . 

Notes: 

1. This dialog is can be used to name Moduie nodes. Node Name changes made in this dialog will 
apply only to the specific instance of the Module selected. The intent is to allow you to label single lines. 
To effect Node Name changes to all instances of the Module, it Is required that the Moduie be selected 
from the Object Tree . 

2. Documentation capability is provided to define the function of the Module, its intended uses, and 
restrictions in use. Documentation changes made in this dialog will apply to all instances of the Module. 

3. You also have the option of selecting for the Module the appropriate Tree Group in the Object Tree . 
Typical Tree Groups include Bit Operations, Arithmetic Operations, Test Modules, etc. 
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Constructing VIVA Modules 

A VIVA Object or Module consists of a graphical device with an associated behavior when connected to 
inputs and/or outputs. When represented graphically, the input nodes are located on the left, and the 
output nodes on the right. For example, consider the following Add module: 



This module has three inputs and two outputs. The inputs consist of two operands and an optional carry 
bit The outputs consist of the sum and a carry bit The carry bit is important for specifying the recursive 
definition of addition, and is useful in many applications. 

To use the addition module, place it on a Behavior Page and connect it to input and output signal lines or 
transports. The following example accepts two inputs, adds them together, and displays the results: 



To create this example first load a library or Sheet containing the addition module using the Open Sheet 



Then place two inputs and an output on the current Behavior Page by dragging them from the Object Tree 

The Object Tree is located in the lower right pane of the VIVA Graphical User Interface. It contains the 
list of available modules. 

To test addition, the types of the inputs must be changed from the default type of bit to something such 
as Int or Byte using the Edit Attributes Dialog . After the correct DataSets have been specified for the 
inputs, connect the inputs and outputs to the add module, and press the Run/Stop Button from the 



■ Add 




command 




ToolBar 
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Behavior Pages 

The Behavior Page is located in the left pane of the Graphical User Interface . The Behavior Page is used 
to define the behavior of a VIVA Module. Unless the Module is Primitive, the Behavior of a Module can 
usually be displayed by drilling into the object To drill, either double click on the object or select the 



object with a left mouse click then dick on the descend icon I 



You execute a Behavior Page by clicking on the Run/Stop button on the ToolBar. 

Definition of VIVA Modules begins with Inputs and Outputs. You place an input on the Behavior Page by 
dragging an Input object from the Object Tree , and dropping it onto the Behavior Page, using Drag and 
Drop. Likewise, you place an Output on the Behavior Page by dragging an Output object from the Object 
Tree and dropping tt onto the Behavior Page, using Drag and Drop. 

Information flow should be designed from left to right. Place the Inputs on the left side of the page and 
the Outputs on the right. 

You then define the behavioral relationship between the inputs and the outputs by connecting them, 
perhaps in series with other Modules, using Transports . The following is the Behavior Page for a NOT, 
AND (or NAND) Module: 




You make the connections or transports between the inputs, outputs, and intervening Modules by clicking 
on one node, moving the mouse to the connecting node, and then clicking again, (See Connecting 
Transports) . If you have a preferred path, you can click the mouse at various points along the desired 
path. 

Junctions are used when it is necessary to split a signal 

Once the behavior is defined, you then convert the behavior sheet to a project Module. Select the 

Convert Sheet to Object command from the File Menu, or select the ToolBar icon, ^B. 

The system will then create a new Module, in this case called NAND, and place it In the Object Tree. The 
NAND Module will have one input node and one output node (corresponding to the aboye Inputs and 
Output) and appear as follows: 



HAND 



This Module may now be used to construct other behavior pages for Modules with more complex 
behavior. 



122 



Node labels for the inputs and outputs of the NAND Module are the same labels on the inputs and 
outputs of the Behavior Page, 
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Connecting Transports 

To make the connections or transports between the inputs, outputs, and intervening Modules, click on 
one node, move the mouse to the connecting node, then click again. If you have a prefeaed path, you 
can click the mouse at various points along the desired path. 



Notes: To facilitate the correct specification of data types, the following conventions or rules have been 
established: 

1 . Default data types for Inputs and Outputs are bits. To change the default type, you must either 
change the DataSet using the Attribute Editor, or connect the Inputs or Outputs to a node with a known 
type. 

2. If a Transport is drawn to an Input or Output with type Bit, this will effect a change of the Input or 
Output to the DataSet to match that of the node to which the transport is connected. 

3. If a Transport is drawn to an art^itrary node of type Variant, this will effect a change of the Node 
DataSet to match that of the node to which the transport is connected. 

4. Nodes are either Input Nodes (Source) or Ou^ut Nodes (Sink). In general, the Input Nodes are 
located on the left side of a Module, with the Output Nodes on the right side. Information flow Is generally 
from the left to the right In general, a Source Node cannot be connected to a Source Node. A 
transportation path can, however, have multiple Sink Nodes by splitting the signal using Junctions. 

5. VIVA will not allow you to connect bA^o nodes with incompatible type. 

6. In some instances, the same signal will go to more than one destination. It becomes necessary to 
create a Junction . This is done by either double clicking on a transport, or by selecting a Junction from 
the Object Tree . 



1 , Node types become evident by their color if the Show Node Type View Node Type Mode is 
activated. Do this by clicking on the ToolBar icon ^S. 

2, A typical way to force a data type is to connect it to a DataSet Exposer or Coljector . For example. 





Hints: 
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dra\Artng a transport from a Variant Exposer to an Input or an Output will force the DataSet of the Input or 
Output to be Variant Moreover, drawing a transport from a Word exposer to an Input will force the 
DataSet of the input to be of type Word. 
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Connecting Junctions 

Junctions are used when ttie same signal needs go to more than one destination. Create a Junction by 
either double clicldng on a transport, or by selecting a Junction from the Object Tree. 
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Convert Sheet To Object Command 

Once you have defined a Behavior Page for a VIVA Module, you can then convert the Behavior Page into 
a VIVA Module, Inputs and outputs of the Module are the same order and type as defined for the 
Behavior Page. Before saving the Module, you are given a final chance to enter the Information about 
the Module (things like giving the Module a name, naming the input and output nodes, and documenting 
the function of the Module and how it is intended to be used). This is done through the Convert Sheet 
Dialog Box. To maintain universality, this interface is essentially the same as the Edit Attributes Dialog 
Box. 



i Convert Sheet to Object 




Notes: 

1. This dialog is probably the best interface provided for naming Module nodes. We recommend you 
name Module nodes here, 

2. Documentation should l>e provided at this point, to define the function of the Module, its intended 
uses, and restrictions in its use. 

3. Overioading is a characteristic that allows you to write several versions of the same behavior to 
handle the various implementation requirements. As a result, you can have three or four different 
addition Modules, In many of these cases, you will use a prior implementation as a template for the new 
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behavior. In these instances, you have the option of either updating the existing Module or creating a 
new one. 

4. You also have the option of selecting for the Module the appropriate Tree Group in the Object Tree . 
Typical Tree Groups include Bit Operations, Arithmetic Operations, Test Modules, and so forth. 
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Object Trees 

The Object Tree is usually displayed in the lower right pane of the main VIVA window of the VIVA 
Graohica! User Interface . Object Tree Groups contain predefined Objects or Modules, as well as 
User-Defined Modules. VIVA also includes fundamental tree groups containing primitive Modules (Bit 
AND, OR, Invert), DataSet Exposers/Collectors . 




The Behavior Page of an individual Module can usually be obtained by double clicking on it. If the Module 
Is needed as part of a VIVA program, it can be placed on the Behavior Page by selecting it, and then 
dragging it to the appropriate position on the Behavior Page. 

Notes: 

1 , New Tree Groups can be created with a right mouse click in the Object Tree Window. 
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2. An object can be moved to a different Tree Group through Drag and Drop, or fay right clicking on the 
item, and selecting a different tree- 
When you create these modules, they are grouped together into one Composite Objectin the Object Tree . 

Overloading allows two different Modules to have the same name, but behave differently, or to operate on 
different DataSets, For example, you can define a Convert module that converts cardinal (unsigned 
integer) to (signed) integer. The conversion from fixed-point arithmetic to signed integer is a different 
species. In particular, bits are discarded. In this case, a different behavior is employed. 

Composite Objects consist of two or more modules with the same name. When you create these 
Modules, they are grouped together into one Composite Object, When doing the component layout, you 
do not need to find the particular Module with the necessary run-time behavior. The composite object 
can be selected, and the particular Module will be elaborated at compile time. In the above example, ttie 
Add, Subtract, Mul, and Divide are all examples of composite objects. 

Inputs and Output DataSets of the composite object will generally be Variant unless all of the different 
implementations agree on frie DataSet for a particular node. For example, the Carry node in an Add 
Module is always of type Bit. 

The composing Modules can be obtained by clicking on \he Composite Object The view then expands, 
revealing ail of the instances of the composing Modules. The following is an expansion of the composite 
Add Object 



The composite Add Object is resolved to two cases. The first case is a Bitwise Add. In some instances, 
you may intend to do a Bitwise Add, and selecting this Module is appropriate. In other instances, the 
polymojphic module will handle them. 

The issues with creating a general polymocphic Module are covered in Constructing Polymorphic Objects . 
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Constructing Polymorphic Objects 

Polymorphism is the characteristic that allows the same behavioral definition to apply to a large variety of 
DataSets, Polymorphismis achieved through a combination of Overloading. Recursion, and Run-Time 
Resolution. 

Overloading allows two different Modules to have the same name, but behave differentiy, or to operate on 
different DataSets, For example, you can define a Convert module that converts cardinal (unsigned 
integer) to (signed) integer. The conversion from fixed-point arithmetic to signed integer is a different 
type of overioading. In particular, Bits are discarded and a different behavior is employed. 

When you create these Modules, they are grouped together into one Composite Object in the Object Tree 
. VIVA resolves the appropriate Module at compile time. In this way, you can program your software to 
wori< in a great variety of applications without having to change the Behavior Page. 

You may ask. "How can one single behavior definition define how to do addition for a variety of 8-bit 
integers, 16-bit integers, signed and unsigned integers, and fixed-point arithmetic?" The answer is in 
Recursion. 

A graphical object, depicted with input and output nodes, is associated with a series of overioaded 
functions, each with the same name, which handle the different implementations of a particular function 
for different types of input. The definitions of Variant Composite Objects can be self-referential, as long 
as the referenced Modules operate on simpler types than the original types. This aile allows recursive 
definitions until the function is broken down into an operation on more fundamental data types. 

Polymorphism is the ability of VIVA Modules to support data types with arbitrary precision using the same 
object or function. DataSet Polymorphism refers to VIVA's ability to elaborate the appropriate GateWare 
implementation depending upon the data type of a variant object's inputs. With Infomiation Rate 
Polymorphism, VIVA selects a particular implementation depending upon the need for speed, 

Overioading is a process whereby multiple objects with the same name can be used to handle different 
application cases. This Polymorphic property is particulariy useful for defining objects to handle Variant 
situations. Additionally, two different definitions can be specified for me same object. 



131 



Modifying an Input 




You create inputs to VIVA Modules by dragging an Input object from the Object Tree , then dropping it 
onto the Behavior Page. To modify the attributes of an input, right click on the Input object and then 
enter values in the Edit Attributes Dialog 

Data provided to the Input is provided from an external interface. The data will be obtained from the node 
at the higher-level connection, or from a Widget, 

To label an input, enter the appropriate name under the name column. The default name is In1. 

The DataSet of the output can be modified by editing the field of the output DataSet If the desired 
DataSet is Int, then the string "Int" should appear in the output DataSet The default DataSet is Bit 
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Modifying an Output 



E Edit AUributes; -^r^' -.-^--, - WMM 




You create Inputs to VIVA Modules by dragging an Input object from the Object Tree and dropping it onto 
the Behavior Page . You modify the attributes of an input by right dicking on the Input object, then 
entering values in the Edit Attributes Dialog . 

The ou^ut data from the Module will be sent to either a higher-leve! connection or a Widget. 

To labeling an output, enter the appropriate name under the name column in the Edit Attributes Dialog 
Box. The default name is Out1. 

The DataSet of the input can be modified by editing \he field of the output DataSet If the desired 
DataSet is Int then the string "Int" should appear in the output DataSet The default DataSet is Bit 
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VIVA Constants 

VIVA constants are a special case of Inputs . Under ordinary circumstances, the inputs on a Behavior 
Page become the nodes of the module at the higher level. By assigning a constant to an Input, this gives 
the capability to assign values to nodes vrfiich are not hooked up. 

A good example of this is In the increment module which increments an arbitrary number by the value of 
a bit. In this example the input cany bit is given a default value of 1. This Is done through the Edit 
Attributes Dialog, which is obtained by clicking on the lower input node using the right mouse button. The 
user then enters Constant 1 in the attributes section of the dialog box. 




In some applications, the user does not want the constant to appear as an input on the higher-level 
page. To prevent the constant from being promoted to an input, the user puts an asterisk in front of the 
constant value. 



In the following example, the behavior page for a module, lnc1 increments by 1, but frie constant does 
not become an input node. 
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VIVA DataSets 

The fundamental DataSet is the Bit A Bit is a single piece of information (ON or OFF. 0 or 1, TRUE or 
FALSE). Other DataSets are formed as aggregates of either bits or more simple DataSets. which are 
ultimately composed of bits. You can define new DataSets by using the DataSet Editor . In addition to the 
Bit. VIVA also supports the following fundamental DataSets: 



DataSet Definition 

Bit The atomic DataSet, consisting of a piece of infomnation with two states (TRUE or 

FALSE. 0 or 1. etc.) 

.DBit Double Bit 2-Bit Cardinal DataSet Pair of Bits. Half a Nibble, Needed to make 

higher-level aggregate DataSets. 

Nibble 4-Bit Cardinal DataSet Half a Byte. Needed to make higher level aggregate DataSets, 

Byte 8-Bit Cardinal DataSet Two Nibbles, 

Word 16-Bit Cardinal DataSet Two Bytes. 

DWord Double Word, 32-Bit Cardinal DataSet Two Words. 

QWord Quad Word, 64-Bit Cardinal DataSet Four Words, 

Int 1 6-Bit Signed Integer. 

Dint 32-Bit Signed Integer. 

QInt 64-Bit Signed Integer. 

Variant The data type does not get elaborated until execution, at which time It is resolved into a 
known DataSet 



A built-in feature of VIVA is the automatic formulation of DataSet Exposers and CoHectors . An Exposer 
Module breaks up a data set into its composing parts; for example, a Word is a concatenation of two 
Bytes. A Collector combines two parts to make a larger DataSet For example, the Word Collector 
combines two Bytes to make a Word, 

The Variant DataSet is used to represent data when the actual DataSet is unknown. This important 
feature enables VIVA to formulate generalized polymorphic Modules that will work Independent of the 
input data types. The VariantOut will compose two arbitrary DataSets into a larger data set The 
resolution of a Variant DataSet exposer into the appropriate DataSet exposer vAW be performed when the 
input data sets become known. 
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DataSet Exposers and Collectors 

For any VIVA DataSet the Exposer and Coliector are automatically defined as part of the language. An 
Exposer Module breaks up a DataSet Into its cx>mponent parts; for example, a Word is a concatenation of 
two Bytes. A Collector combines two parts to make a larger DataSet For example, the Word Collector 
combines two Bytes to make a Word. The names of the Exposer and Collector are formulated by 
appending the characters "In" and *Ouf to the DataSet name. For example, ttie Wordin Exposer breaks 
up a word into its two composing types. The WordOut Collector takes two Bytes and puts them together 
to make a word. 
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Note 1: The Bit is the fundamental data set, and has neither a collector nor an exposer. Any attempt to 
break up a Bit into its composing parts will result in an error. 

Note 2: The Variantin will split an arbitrary DataSet set into two composing parts. This important feature 
enables VIVA to formulate generalized polymorphic Modules that will work independent of the input data 
types. The VariantOut will compose two arbitrary DataSets Into a larger data set The resolution of a 
Variant DataSet exposer into the appropriate DataSet exposer will be performed when the input data sets 
become known. 

WARNING 

In some cases, DataSet Collectors may not be unique. For example a 16-bit signed integer and a 16-bit 
cardinal (unsigned integer) are both composed from a pair of Bytes. The collector is ambiguous. In this 
case, VIVA will select the more fundamental exposer To compose two Bytes into an Int requires that 
either that lnK)ut be explicitly specified, or that the output of the Variant Collector be Cast as an integer 
using the generic system Cast Operator 
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Forcing GateWare Allocation 

To force any particular VIVA Module into a particular system, set the System Attribute String of the 
Module to contain the desired system: 

1 . Right click on the Module. This brings up the Edit Attributes Dialog Box . 

2. Under the left attributes column, enter the text, ChUdAttnbute 

3. Under the right attributes column enter the text, "System=XPo/nr, (See panel below.) 

4. Press the OK button. 
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ASIC 

Application-specific integrated circuit 
Behavior 

The functional characteristics of a VIVA Moduie, Example: The Behavior of an add object is to take two 
inputs, add them together, and send the result to the output 

Byte 

An aggregate data type consisting of 8 bits. Byte arithmetic is considered to be unsigned integer. 
Cardinal 

A numeric interpretation where a string of bits is interpreted as an unsigned integer. Byte, Word, DWord, 
and Huge are all Cardinal number types. 

Clock 

The VIVA event that is clock driven, usually at regulariy timed intervals. 
Collector 

A Module that assembles a collection of DataSets into a Composite DataSet ; 
Composite Object 

A VIVA Object composed of Inputs, outputs, and more primitive Objects connected by Transports. 
Fppu 

^pen^i processing unit for a serial computer, usually a microprocessor. 
Tpata-flow machine 

J!a computer whose data-driven architecture has instructions available for concurrent execution rather than 
LJsequentiai execution. 

^toBit 

Double Bit. 2-Bit Cardinal DataSet. A pair of Bits, Half a Nibble. 

r; DBitIn 

The DataSet Exposer Module of DBit 

U DBItOut 

5 The DataSet Collector Module of DBit 

"Done 

The VIVA event tiiat indicates that tiie Module has been executed. 
Drill 

To highlight and to expose additional information about the Module. 
Event 

In VIVA, a change of state that occurs in time. Examples include ready, wait, go, and done, 
Exposer 

A VIVA Module that separates a Composite Object into its component parts, 
FPGA 

Field programmable gate array, 
GateWare 

A VIVA implementation created through VIVA. GateWare'™ is a trademark of Star Bridge Systems. Inc, 
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Go 

The VIVA event that signals another Module to begin execution. 
GUI 

Graphical user interface. 
Integer 

A numeric interpretation of a string of bits in which the highest bit is interpreted as a sign bit. Negative 
values are represented as 2's complement 

Libraiy 

A collection of software Objects or Modules that can be accessed by a user and incorporated into a 
project. VIVA implements Libraries as sheets of objects. 

Module 

A graphical device with an associated behavior when connected to inputs and/or outputs. Also called 
Object. 

Object 

A graphical device with an associated behavior when connected to Inputs and/or outputs. For precision, 
we prefer to use the term Module in VIVA, 

□ Overloading 

a process whereby multiple objects with the same name can be used to handle different application 
Q cases. This polymorphic property is particulariy useful for defining objects to handle variant situations. 
-^Additionally, two different definitions can be specified for the same object. 

Parallel 

^L'The simultaneous execution of multiple circuits rather than a single path. 
I y Persistence 

- The ability to save VIVA object code (GateWare) on storage media such as a hard disk, 
f y Polymorphism 

m The ability of a VIVA Module to support data types with arbitrary precision using the same object or 



DataSet Polymorphism refers to VIVA's ability to instantiate tiie appropriate GateWare 
depending upon the data type of a variant object's inputs. 

Information Rate Polymorphism refers to VIVAs ability to instantiate the appropriate GateWare 
depending upon the need for speed. 

Ready 

The VIVA event that notifies another Module that it is ready to receive data. 
Recursion 

The ability of a function to call itself. 



fii function. 



Reset 

The VIVA event that signals a Module to reset. 



Resolution 

The process of determining the meaning of an abstract concept for a particular application. 
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Sync 

The VIVA event that synchronizes the start of execution of two or more processes. 
Variant 

An attribute that could have multiple meanings, depending on the application, 
VIVA 

The operating system, language, and user Interface created by Kent L. Gilson. VIVA"^ is a trademark of 
Star Bridge Systems, Inc. 

Wait 

The VIVA event that signals another Module that it is not ready to receive data. 
Wire list 

The topology of a circuit, showing the devices and their connections. On an FPGA, it shows the state of 
each gate and the connections between them. 
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